Add support for Jujutsu conflict markers by rf- · Pull Request #64750 · microsoft/TypeScript

Ryan Fitzgerald (rf-) · 2026-10-12T18:56:55Z

By default, the Jujutsu VCS represents
conflicts using a different style than Git. The overall conflict area is
still delimited by <<<<<<< and >>>>>>> lines, but the intermediate
sections are separated by %, \, +, and/or - characters instead
of = and |.

We have two basic requirements for handling conflict areas:

The conflict markers themselves should be flagged as errors, and the
compiler should ignore all other text on each marker line.
Exactly one version of the conflicted code should be processed by the
compiler, and any other conflict sections should be ignored. This
reduces the odds of spurious errors showing up in surrounding code.

With Git conflicts, these goals can be achieved without keeping any
state between markers. Each call to scanConflictMarkerTrivia() handles
one marker line, and the call for each intermediate marker also consumes
other file content until the next intermediate marker, while leaving the first
section after <<<<<<< to be scanned normally.

Jujutsu conflicts are trickier. The <<<<<<< line is followed by
another marker line, not the actual content, and there may be multiple
"snapshot" sections marked by +++++++ lines that contain content from
different commits. We want to scan one of these sections but omit any
others, so we need to keep a flag tracking whether we've allowed one to
be scanned yet.

Another subtlety here is that if the file contains any lines that look
like normal-length conflict markers, Jujutsu will use longer markers to
disambiguate. Handling this correctly requires us to track the length of
the markers in the current conflicted section.

Points of interest:

There's a private couldStartTrivia() function that I would have had
to update to keep in sync with skipTrivia(), but it seems to just be
dead code. This commit deletes it.
The old code is picky about whitespace after the initial marker
string, requiring a space character after anything but =. This is
simplified now so that any marker string can be followed by either a
space or a newline.

This adds a test case for each of the scenarios described in the Jujutsu
docs (default style, snapshot style, longer markers, and missing
terminating newline) and one for CRLF line endings.

typescript-automation · 2026-10-12T18:57:01Z

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Copilot

🟢 Approval recommended

The scanner changes are consistent with existing conflict-marker handling and comprehensively covered by compiler baselines.

0 open findings

What changed in this PR

Adds native compiler support for Jujutsu-style conflict markers.

Changes:

Recognizes %, \, and + conflict separators.
Extends conflict-trivia scanning and skipping.
Adds compiler coverage and expected baselines.

File	Description
`tsc/internal/scanner/scanner.go`	Recognizes and skips Jujutsu conflict sections.
`tsc/testdata/tests/cases/compiler/conflictMarkerJujutsuTrivia1.ts`	Exercises all Jujutsu marker forms.
`tsc/testdata/baselines/reference/compiler/conflictMarkerJujutsuTrivia1.errors.txt`	Verifies TS1185 diagnostics.
`tsc/testdata/baselines/reference/compiler/conflictMarkerJujutsuTrivia1.js`	Verifies conflicted code is omitted from emit.
`tsc/testdata/baselines/reference/compiler/conflictMarkerJujutsuTrivia1.symbols`	Verifies unaffected symbol discovery.
`tsc/testdata/baselines/reference/compiler/conflictMarkerJujutsuTrivia1.types`	Verifies unaffected type discovery.

🧠 Review effort: Balanced

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

Ryan Fitzgerald (rf-) · 2026-10-12T19:00:32Z

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Is this mandatory or just a nice-to-have? I'm happy to do it if any maintainers feel like it's necessary/helpful in this case, but not sure if it's needed here.

Ryan Fitzgerald (rf-) · 2026-10-12T19:01:14Z

@microsoft-github-policy-service agree

Jake Bailey (jakebailey) · 2026-10-12T19:01:53Z

TypeScript Bot (@typescript-bot) perf test this faster

typescript-automation · 2026-10-12T19:01:59Z

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
`perf test this faster`	✅ Started	👀 Results

typescript-automation · 2026-10-12T19:32:28Z

Jake Bailey (@jakebailey)
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-Unions - native}
_Errors	₄₁	₄₁	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_115,276	_115,276	_~	_~	_~	_{p=1.000 n=12}
_Types	_79,613	_79,613	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{133,837k (± 0.03%)}	_{133,895k (± 0.06%)}	_~	_133,695k	_134,121k	_{p=0.561 n=12}
_{Memory Allocs}	_{2,190,072 (± 0.01%)}	_{2,190,044 (± 0.00%)}	_~	_2,189,785	_2,190,284	_{p=0.843 n=12}
_{Config Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.049s (± 3.21%)}	_{0.050s (± 3.32%)}	_~	_0.046s	_0.054s	_{p=0.243 n=12}
_{Bind Time}	_{0.017s (±12.00%)}	_{0.015s (± 9.76%)}	_~	_0.012s	_0.019s	_{p=0.413 n=12}
_{Check Time}	_{0.596s (± 0.47%)}	_{0.599s (± 0.51%)}	_~	_0.593s	_0.607s	_{p=0.310 n=12}
_{Emit Time}	_{0.323s (± 2.09%)}	_{0.328s (± 2.07%)}	_~	_0.316s	_0.349s	_{p=0.324 n=12}
_{Total Time}	_{0.992s (± 0.56%)}	_{1.000s (± 0.71%)}	_~	_0.987s	_1.023s	_{p=0.066 n=12}
_{angular-1 - native}
_Errors	₃	₃	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_{845,785 (± 0.07%)}	_{845,600 (± 0.09%)}	_~	_843,142	_847,125	_{p=0.887 n=12}
_Types	_{248,125 (± 0.00%)}	_{248,125 (± 0.00%)}	_~	_248,122	_248,127	_{p=0.877 n=12}
_{Memory Used}	_{750,371k (± 0.01%)}	_{750,514k (± 0.02%)}	_~	_750,107k	_750,845k	_{p=0.101 n=12}
_{Memory Allocs}	_{12,916,135 (± 0.05%)}	_{12,925,370 (± 0.11%)}	_~	_12,910,905	_12,983,785	_{p=0.101 n=12}
_{Config Time}	_{0.020s (± 1.59%)}	_{0.020s (± 1.60%)}	_~	_0.020s	_0.021s	_{p=1.000 n=12}
_{Parse Time}	_{0.320s (± 2.02%)}	_{0.320s (± 2.62%)}	_~	_0.286s	_0.338s	_{p=0.921 n=12}
_{Bind Time}	_{0.072s (± 1.76%)}	_{0.079s (±12.40%)}	_~	_0.068s	_0.112s	_{p=0.712 n=12}
_{Check Time}	_0s	_0s	_~	_~	_~	_{p=1.000 n=12}
_{Emit Time}	_{1.870s (± 0.91%)}	_{1.869s (± 1.12%)}	_~	_1.820s	_1.937s	_{p=0.765 n=12}
_{Total Time}	_{2.298s (± 0.81%)}	_{2.304s (± 1.18%)}	_~	_2.248s	_2.403s	_{p=0.723 n=12}
_{mui-docs - native}
_Errors	_11,405	_11,405	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_4,359,614	_4,359,614	_~	_~	_~	_{p=1.000 n=12}
_Types	_1,376,379	_1,376,379	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{2,813,817k (± 0.05%)}	_{2,813,443k (± 0.05%)}	_~	_2,810,170k	_2,817,135k	_{p=0.671 n=12}
_{Memory Allocs}	_{32,814,088 (± 0.05%)}	_{32,810,969 (± 0.04%)}	_~	_32,783,251	_32,847,888	_{p=0.843 n=12}
_{Config Time}	_0.017s	_0.017s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.503s (± 3.64%)}	_{0.509s (± 2.29%)}	_~	_0.466s	_0.534s	_{p=0.744 n=12}
_{Bind Time}	_0.002s	_0.002s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{8.637s (± 0.54%)}	_{8.603s (± 0.59%)}	_~	_8.494s	_8.739s	_{p=0.247 n=12}
_{Emit Time}	_{0.453s (± 9.12%)}	_{0.450s (± 9.42%)}	_~	_0.417s	_0.600s	_{p=0.068 n=12}
_{Total Time}	_{10.383s (± 0.62%)}	_{10.340s (± 0.63%)}	_~	_10.210s	_10.508s	_{p=0.242 n=12}
_{strada-build-src - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,390,229	_1,390,229	_~	_~	_~	_{p=1.000 n=12}
_Types	_441,498	_441,498	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{1,632,907k (± 1.04%)}	_{1,641,907k (± 0.99%)}	_~	_1,604,427k	_1,685,990k	_{p=0.514 n=12}
_{Memory Allocs}	_{92,075,010 (± 0.19%)}	_{92,145,227 (± 0.19%)}	_~	_91,492,621	_92,399,336	_{p=0.347 n=12}
_{Config Time}	_{0.004s (±14.34%)}	_{0.003s (±16.58%)}	_~	_0.002s	_0.005s	_{p=0.966 n=12}
_{Parse Time}	_{0.196s (± 3.56%)}	_{0.204s (± 4.16%)}	_~	_0.177s	_0.222s	_{p=0.110 n=12}
_{Bind Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{1.795s (± 0.71%)}	_{1.801s (± 0.89%)}	_~	_1.775s	_1.870s	_{p=0.831 n=12}
_{Emit Time}	_{0.300s (± 4.30%)}	_{0.304s (± 3.13%)}	_~	_0.272s	_0.327s	_{p=0.788 n=12}
_{Total Time}	_{23.283s (± 0.42%)}	_{23.474s (± 0.56%)}	_{+0.191s (+ 0.82%)}	_23.141s	_23.795s	_{p=0.033 n=12}
_{strada-compiler - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_334,953	_334,953	_~	_~	_~	_{p=1.000 n=12}
_Types	_197,616	_197,616	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{297,324k (± 0.02%)}	_{297,364k (± 0.03%)}	_~	_297,077k	_297,624k	_{p=0.347 n=12}
_{Memory Allocs}	_{4,621,212 (± 0.01%)}	_{4,621,474 (± 0.01%)}	_~	_4,619,777	_4,623,292	_{p=0.799 n=12}
_{Config Time}	_0.001s	_0.001s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.115s (± 5.11%)}	_{0.117s (± 3.22%)}	_~	_0.107s	_0.127s	_{p=0.434 n=12}
_{Bind Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{1.038s (± 0.63%)}	_{1.038s (± 0.38%)}	_~	_1.030s	_1.052s	_{p=0.876 n=12}
_{Emit Time}	_{0.142s (± 8.58%)}	_{0.150s (± 6.92%)}	_~	_0.122s	_0.172s	_{p=0.401 n=12}
_{Total Time}	_{1.349s (± 0.81%)}	_{1.359s (± 1.05%)}	_~	_1.322s	_1.384s	_{p=0.235 n=12}
_{ts-pre-modules - native}
_Errors	₈₇	₈₇	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_303,834	_303,834	_~	_~	_~	_{p=1.000 n=12}
_Types	_181,663	_181,663	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{258,185k (± 0.02%)}	_{258,136k (± 0.01%)}	_~	_258,063k	_258,189k	_{p=0.060 n=12}
_{Memory Allocs}	_{1,613,752 (± 0.01%)}	_{1,613,659 (± 0.01%)}	_~	_1,613,156	_1,613,999	_{p=0.660 n=12}
_{Config Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.099s (± 4.15%)}	_{0.100s (± 3.84%)}	_~	_0.092s	_0.113s	_{p=0.876 n=12}
_{Bind Time}	_{0.039s (±10.55%)}	_{0.040s (±14.96%)}	_~	_0.027s	_0.059s	_{p=0.921 n=12}
_{Check Time}	_{0.813s (± 0.98%)}	_{0.817s (± 0.77%)}	_~	_0.805s	_0.837s	_{p=0.401 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{0.965s (± 1.01%)}	_{0.971s (± 0.64%)}	_~	_0.956s	_0.986s	_{p=0.235 n=12}
_{vscode - native}
_Errors	₃₉₅	₃₉₅	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_11,287,880	_11,287,880	_~	_~	_~	_{p=1.000 n=12}
_Types	_3,740,417	_3,740,417	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{6,523,082k (± 0.01%)}	_{6,522,944k (± 0.02%)}	_~	_6,521,326k	_6,527,012k	_{p=0.401 n=12}
_{Memory Allocs}	_{55,464,608 (± 0.01%)}	_{55,468,118 (± 0.02%)}	_~	_55,453,947	_55,512,470	_{p=0.671 n=12}
_{Config Time}	_{0.075s (± 0.33%)}	_{0.075s (± 0.56%)}	_~	_0.074s	_0.076s	_{p=1.000 n=12}
_{Parse Time}	_{1.869s (± 3.39%)}	_{1.847s (± 3.64%)}	_~	_1.723s	_2.011s	_{p=0.641 n=12}
_{Bind Time}	_{0.585s (±21.42%)}	_{0.583s (±17.42%)}	_~	_0.442s	_0.869s	_{p=0.966 n=12}
_{Check Time}	_{14.062s (± 1.04%)}	_{14.060s (± 1.22%)}	_~	_13.651s	_14.312s	_{p=0.601 n=12}
_{Emit Time}	_{4.769s (±11.22%)}	_{4.815s (±10.58%)}	_~	_4.119s	_6.099s	_{p=0.799 n=12}
_{Total Time}	_{21.443s (± 2.19%)}	_{21.468s (± 1.84%)}	_~	_20.913s	_22.507s	_{p=0.744 n=12}
_{webpack - native}
_Errors	₅₈₄	₅₈₄	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,321,840	_1,321,840	_~	_~	_~	_{p=1.000 n=12}
_Types	_624,651	_624,651	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{957,970k (± 0.02%)}	_{957,754k (± 0.01%)}	_{-216k (- 0.02%)}	_957,426k	_958,212k	_{p=0.018 n=12}
_{Memory Allocs}	_{6,693,193 (± 0.04%)}	_{6,691,530 (± 0.02%)}	_~	_6,689,804	_6,696,869	_{p=0.378 n=12}
_{Config Time}	_0.009s	_0.009s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.292s (± 4.05%)}	_{0.294s (± 3.16%)}	_~	_0.269s	_0.319s	_{p=0.744 n=12}
_{Bind Time}	_{0.097s (±19.14%)}	_{0.083s (±15.64%)}	_~	_0.063s	_0.124s	_{p=0.369 n=12}
_{Check Time}	_{1.878s (± 1.07%)}	_{1.891s (± 0.89%)}	_~	_1.846s	_1.927s	_{p=0.433 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{2.312s (± 0.65%)}	_{2.313s (± 0.71%)}	_~	_2.269s	_2.352s	_{p=0.876 n=12}
_{xstate-main - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,061,928	_1,061,928	_~	_~	_~	_{p=1.000 n=12}
_Types	_389,645	_389,645	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{554,311k (± 0.02%)}	_{554,329k (± 0.02%)}	_~	_554,140k	_554,744k	_{p=0.945 n=12}
_{Memory Allocs}	_{4,881,429 (± 0.04%)}	_{4,882,938 (± 0.09%)}	_~	_4,873,521	_4,893,356	_{p=0.514 n=12}
_{Config Time}	_0.003s	_0.003s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.144s (± 3.79%)}	_{0.149s (± 4.58%)}	_~	_0.135s	_0.169s	_{p=0.399 n=12}
_{Bind Time}	_{0.045s (±21.00%)}	_{0.046s (±15.73%)}	_~	_0.033s	_0.065s	_{p=0.575 n=12}
_{Check Time}	_{1.129s (± 0.80%)}	_{1.138s (± 1.00%)}	_~	_1.113s	_1.169s	_{p=0.155 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{1.329s (± 0.73%)}	_{1.346s (± 0.98%)}	_{+0.017s (+ 1.26%)}	_1.310s	_1.372s	_{p=0.027 n=12}

System info unknown

Hosts

native

Scenarios

Compiler-Unions - native
angular-1 - native
mui-docs - native
strada-build-src - native
strada-compiler - native
ts-pre-modules - native
vscode - native
webpack - native
xstate-main - native

_Benchmark	_Name	_Iterations
_Current	_pr	₁₂
_Baseline	_baseline	₁₂

Developer Information:

Download Benchmarks

Ryan Cavanaugh (RyanCavanaugh) · 2026-10-13T16:31:55Z

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Is this mandatory or just a nice-to-have? I'm happy to do it if any maintainers feel like it's necessary/helpful in this case, but not sure if it's needed here.

An issue would be a better place to sort out the comments that are currently being discussed in the code review (e.g. what are the actual observed forms of the conflict marker?).

Ryan Fitzgerald (rf-) · 2026-10-14T03:01:54Z

Good points, thanks Jake Bailey (@jakebailey)! Apologies for not covering all of the possible formats, it definitely makes sense to do them all at once. I'll open an issue to ref in the PR.

Ryan Fitzgerald (rf-) · 2026-10-17T16:59:13Z

Coming back to this, one thing I'm confused about is the couldStartTrivia function. It seems like it's been dead code in Go since it was added. I'm wondering if maybe it was only retained in the TypeScript codebase because it's exported, and then in Go it's just vestigial and should be removed?

Jake Bailey (jakebailey) · 2026-10-19T22:19:57Z

I think we can probably just do the simple easy version of this and it be sufficient; this is a best effort recovery after all so I think that's ok.

Ryan Fitzgerald (rf-) · 2026-10-25T23:44:59Z

Jake Bailey (@jakebailey) I ended up feeling like it was worth it to just bite the bullet and do it correctly, since parsing one side of the conflict instead of dropping everything makes a big difference to the editor experience. I just pushed an update that should hopefully address everything that's come up 🙏

Copilot

🟡 Changes recommended

Bare markers at EOF can panic, and CRLF conflicts discard every snapshot instead of preserving one version.

2 open issues

_{Review effort: Balanced}

Copilot

🟡 Changes recommended

Shared conflict-state mutation breaks scanner rewind behavior, and consecutive skipped snapshots can lose required marker diagnostics.

2 open issues

2 resolved since last review

_{Review effort: Balanced}

By default, the [Jujutsu](https://github.com/jj-vcs/jj) VCS represents conflicts using a different style than Git. The overall conflict area is still delimited by `<<<<<<<` and `>>>>>>>` lines, but the intermediate sections are separated by `%`, `\`, `+`, and/or `-` characters instead of `=` and `|`. We have two basic requirements for handling conflict areas: - The conflict markers themselves should be flagged as errors, and the compiler should ignore all other text on each marker line. - Exactly one version of the conflicted code should be processed by the compiler, and any other conflict sections should be ignored. This reduces the odds of spurious errors showing up in surrounding code. With Git conflicts, these goals can be achieved without keeping any state between markers. Each call to `scanConflictMarkerTrivia()` handles one marker line, and the call for each intermediate marker also consumes the content until the next intermediate marker, while leaving the first section after `<<<<<<<` to be scanned normally. Jujutsu conflicts are trickier. The `<<<<<<<` line is followed by another marker line, not the actual content, and there may be multiple "snapshot" sections marked by `+++++++` lines that contain content from different commits. We want to scan one of these sections but omit any others, so we need to keep a flag tracking whether we've allowed one to be scanned yet. Another subtlety here is that if the file contains any lines that look like normal-length conflict markers, Jujutsu will use longer markers to disambiguate. Handling this correctly requires us to track the length of the markers in the current conflicted section. Points of interest: - There's a private `couldStartTrivia()` function that I would have had to update to keep in sync with `skipTrivia()`, but it seems to just be dead code. This commit deletes it. - The old code is picky about whitespace after the initial marker string, requiring a space character after anything but `=`. This is simplified now so that any marker string can be followed by either a space or a newline. This adds a test case for each of the scenarios described in the Jujutsu docs (default style, snapshot style, longer markers, and missing terminating newline) and one for CRLF line endings.

Copilot

🟡 Changes recommended

Mid-conflict trivia scanning loses marker-width context, and JSX scanning can process discarded conflict sections.

2 open issues

2 resolved since last review

_{Review effort: Balanced}

Ryan Fitzgerald (rf-) · 2026-10-26T02:52:15Z

+				if isConflictMarkerTrivia(s.text, s.pos, s.conflictState) {
+					s.pos, s.conflictState = scanConflictMarkerTrivia(s.text, s.pos, s.conflictState, s.errorAt)


Is this related to this PR? If the existing JSX scanner doesn't handle intermediate markers properly in general, then fixing that doesn't seem in scope here 🤔

Yeah, conflicts inside JSX are not working well on main now from either an error or codegen perspective. I think fixing that is a bit above my pay grade, but I don't think this is making it any worse—the current code already doesn't handle ||| or === markers at all, so adding the jj markers doesn't matter too much.

Ryan Fitzgerald (rf-) · 2026-10-26T03:02:24Z

+
+	// Now that we've established we don't want to scan this section, consume
+	// everything up to the start of the next marker.
+	for pos < length {


Hmm, OK. This seems very edge casey IIUC, and it's still not solving the broader issue that SkipTriviaEx doesn't know the expected marker length if it starts halfway through a conflict area, but it seems reasonable to initialize the state if we start at an intermediate marker.

Actually the hard part here is the test case—SkipTriviaEx itself doesn't have tests, and I don't know what call site would make sense to try to test this from. It would probably make sense to use one where this situation is likely to come up and would have a meaningful impact, but I'm not sure if that exists.

Copilot AI balanced review requested due to automatic review settings October 12, 2026 18:56

github-project-automation Bot added this to PR Backlog Oct 12, 2026

typescript-automation Bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 12, 2026

Copilot started reviewing on behalf of Ryan Fitzgerald (rf-) October 12, 2026 18:57

View session

Copilot AI reviewed Oct 12, 2026

View reviewed changes

Jake Bailey (jakebailey) reviewed Oct 13, 2026

View reviewed changes

Comment thread tsc/internal/scanner/scanner.go Outdated

Comment thread tsc/internal/scanner/scanner.go Outdated

Jake Bailey (jakebailey) reviewed Oct 13, 2026

View reviewed changes

Comment thread tsc/testdata/tests/cases/compiler/conflictMarkerJujutsuTrivia1.ts

Ryan Fitzgerald (rf-) marked this pull request as draft October 17, 2026 17:50

Ryan Fitzgerald (rf-) mentioned this pull request Oct 17, 2026

Support Jujutsu conflict markers #64852

Open

6 tasks done

Ryan Fitzgerald (rf-) force-pushed the support-jujutsu-conflicts branch from 32321db to 05caab8 Compare October 25, 2026 23:41

Ryan Fitzgerald (rf-) force-pushed the support-jujutsu-conflicts branch from 05caab8 to 17b4024 Compare October 25, 2026 23:50

Ryan Fitzgerald (rf-) marked this pull request as ready for review October 25, 2026 23:52

Ryan Fitzgerald (rf-) requested review from Jake Bailey (jakebailey) and a balanced review from Copilot October 25, 2026 23:52

Copilot started reviewing on behalf of Ryan Fitzgerald (rf-) October 25, 2026 23:53

View session

Copilot AI reviewed Oct 25, 2026

View reviewed changes

Comment thread tsc/internal/scanner/scanner.go

Comment thread tsc/internal/scanner/scanner.go

Ryan Fitzgerald (rf-) marked this pull request as draft October 26, 2026 00:48

Ryan Fitzgerald (rf-) force-pushed the support-jujutsu-conflicts branch from 17b4024 to d83049d Compare October 26, 2026 01:07

Ryan Fitzgerald (rf-) requested a balanced review from Copilot October 26, 2026 01:08

Copilot started reviewing on behalf of Ryan Fitzgerald (rf-) October 26, 2026 01:09

View session

Copilot AI reviewed Oct 26, 2026

View reviewed changes

Comment thread tsc/internal/scanner/scanner.go Outdated

Comment thread tsc/internal/scanner/scanner.go Outdated

Ryan Fitzgerald (rf-) force-pushed the support-jujutsu-conflicts branch from d83049d to ff25e77 Compare October 26, 2026 02:41

Ryan Fitzgerald (rf-) requested a balanced review from Copilot October 26, 2026 02:41

Copilot started reviewing on behalf of Ryan Fitzgerald (rf-) October 26, 2026 02:42

View session

Copilot AI reviewed Oct 26, 2026

View reviewed changes

Ryan Fitzgerald (rf-) marked this pull request as ready for review October 26, 2026 04:46

		if isConflictMarkerTrivia(s.text, s.pos, s.conflictState) {
		s.pos, s.conflictState = scanConflictMarkerTrivia(s.text, s.pos, s.conflictState, s.errorAt)

Conversation

Ryan Fitzgerald (rf-) commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

typescript-automation Bot commented Oct 12, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

Ryan Fitzgerald (rf-) commented Oct 12, 2026

Uh oh!

Ryan Fitzgerald (rf-) commented Oct 12, 2026

Uh oh!

Jake Bailey (jakebailey) commented Oct 12, 2026

Uh oh!

typescript-automation Bot commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

typescript-automation Bot commented Oct 12, 2026

tsc

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Ryan Cavanaugh (RyanCavanaugh) commented Oct 13, 2026

Uh oh!

Ryan Fitzgerald (rf-) commented Oct 14, 2026

Uh oh!

Ryan Fitzgerald (rf-) commented Oct 17, 2026

Uh oh!

Jake Bailey (jakebailey) commented Oct 19, 2026

Uh oh!

Ryan Fitzgerald (rf-) commented Oct 25, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Ryan Fitzgerald (rf-) Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ryan Fitzgerald (rf-) Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ryan Fitzgerald (rf-) Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

Ryan Fitzgerald (rf-) Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Ryan Fitzgerald (rf-) commented Oct 12, 2026 •

edited

Loading

typescript-automation Bot commented Oct 12, 2026 •

edited

Loading

Ryan Fitzgerald (rf-) Oct 26, 2026 •

edited

Loading

Ryan Fitzgerald (rf-) Oct 26, 2026 •

edited

Loading